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(57) Abstract: The invention concerns a method for loading 
application in a multiapplication onplatform system, the 
conesponding onplatform system, and the method for executing 
an ^)plication of the onplatfonn system. The system for 
^^lication loading on an onplatform system comprising a 
execution environment including a virtual machine compcising 
a language interpreter of the intgrnediate pseudocode type, 
^>plication programming interfaces (API), from a station 
whereon the application source code is written, compiled in 
pseudocode, verified and converted is characterised in that 
the conversion comprises steps which consist in: producing 
a static linkage of a plurality of packages to be stored in die 
same name space on the onplatform system, called modules, and 
constituting an ^plication programming interface module or a 
service module corresponding to an application, and consists in 
assigning an identifier to each module (MID), and a reference 
numb^ to each class (NO)* to each m^od (NM) and to each 
attribute (NA). The reference to a method or an attribute in the 
pseudocode linked to a module is coded on three multiplets 
formed by an indicator signalling the reference to a class internal 
(n) or an external (BE) to the module, die class numbo' (NO) 
and either the method number (NM) or the attribute number 
(NA), a reference (IE) to an external class being systematically 
intetineted by the virtual machine as a reference to an application 
programming interface module. 



[Suite sur la page suivante] 



wo 01/37085 Al IDlHIllilflinilliliiliilli 



(74) Mandataire: CORLU, Bernard; Bull S^, PC58D20. 
68, route de Versailles, F-78434 Louveciomes Cedex (FR). 

(81) Etats design^ (national): BR, CA, CN, JP, US. 

(84) Etats d^ignes (regional)-, brevet emope^ (AT, BE, CH, 
CY,DE,DK, ES,FI,FR,GB.GR,IE,IT,LU,MC,NL,PT. 
SE,TR), 



Publiee: 

— Avec rapport de recherche intemationale. 

En ce qui conceme les codes a deux lettres et autres abrevia- 
tions, se referer awe "Notes explicattves relatives awt codes et » 
abreviations" figta-ant au debut de chaque numero ordinaire de 
la Gazette du PCT. 



(57) Abr^^: La pr^nte invention conceme un proc^d^ de chargement d* applications dans un syst^me embaiqu^ nuilti-^plication, 
le syst^me embarqu^ correspondant, et le proc^d^ d*ex^cution d*une application du systeme embarqu^. Le pioc6d^ de chaigement 
d' applications sur un systeme embaiqud compicnant un environnement d'ex6cution incluant une machine viituelle compienant un 
intetpi^teur de langage de type pseudocode intenn^diaire, des interfaces de iHX>grammation d'q}plication (API), k partir d*une station 
sur laquelle le code source de Tapplication est ^crit> compile en pseudocode, vdrifid et converti, se caract^ise n ce que la conversi n 
conqHend la r^alisati n de la liaison statique d'une plurality d'ensemble de paquetages destines k etre stocks dans le m€xne espace 
nom sur le systeme embarqu^, appel^ modules, ^ constituant un module d' interface de programmation d* application ou un module 
de service correspondant k line application, et consiste k attribuer un identificateur a chaque module (MID), et un numero de r^e- 
rence k chaque classe (NO), k chaque m^diode (NM) et k chaque attribut (NA). La r^i^rence a une m^tfaode ou un attribut, dans le 
ps^docode Vi€ d'un module est cod^ sur tzois nuiltiplets consthu^ par un indicateur indiquant la i€f£r»ice h une classe intmie (II) 
ou exteme (IE) au module, le num^ de la classe (NCI) et soit le numero de la m^thode (NM) soit le num^ de rattiibut (NA), une 
r^ffrence (IE) k une classe exteme etant syst^matiquement interpret^ par la machine virtueUe comme ui^ r&i^sxaiCG k un module 
d'int^ace de (HOgrammation duplication. 
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PROCEDE DE CHARGEMENT D'APPUCAnONS DANS UN SYSTEME EMBARQUE MULTI-APPUCAnON 
MUNI DE RESSOURCES DE TRATIEMENT DE DONNEES. SYSTEME, ET PROCEDE D'EXECUnON CX)RRESPON- 
DANTS 



5 La presente invention concerne un procede de chargement 

d'applications dans un systeme embarque multi-application, muni de 
ressources de traitement de donnees, le systeme embarque correspondant, 
et le procede d'execution d'une application d'un systeme embarque 
correspondant. 

10 La presente invention concerne plus particuliere la realisation de 

pare-feu entre modules partageant le meme espace memoire dans des 
systemes embarques sur des objets portables multi-application utilisant un 
pseudocode intermediaire et une machine virtuelle associee. 

La technologie "Java" (marque deposee) introduite par la societe 

15 "Sun" est basee sur un langage de programmation oriente objet "Java" et 
une machine virtuelle associee. Cette technologie a ete developpee sur des 
stations ou PC (Personal Computer), appelees ci-apres plate-forme "Java" 
classique, possedant une puissance CPU et une memoire importante de 
Tordre du mega byte ou megaoctet. 

20 Depuis quelques annees, les concepts de la technologie "Java" ont 

ete repris et adaptes pour fonctionner sur des systemes embarques dans 
des objets portables, par exemple au format de carte de credit ou 
micromodule SIM incorporant un microprocesseur et appelee communement 
carte a puce, ou encore de telephones portables GSM (Global System for 

25 Mobile Communication), cartes PCMCIA ou tous autres terminaux portables. 
Par la suite nous utiliserons le terme carte pour designer I'un quelconque de 
ces objets portables. La programmation des systemes embarques, jusqu'ici 
r^alisee en assembleur, est desormais possible dans un langage evolue 
comme "Java", et permet de faciliter et d'accelerer le developpement 

30 d'applications clientes. 
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Ce nouveau type de plate-forme specifique aux systemes 
embarques d'un objet portable, appele ci-apres plate-forme specifique, 
constitue un sous-ensemble de la plate-forme classique. Les differences 
resultent du fait de Tenvironnement reduit des systemes embarques. De 
5 maniere classique, tel que represents a la figure 4a, une carte a puce (10) 
comprend un systeme d'entree et de sortie (11) relie au microprocesseur 
(14), une memoire volatile RAM (12) (Random Access Memory) une 
memoire non volatile constituee par une memoire morte ROM (13) (Read 
Only Memory) et une memoire non volatile programmable (15) constituee 

10 d'une flash RAM ou EEPROM (Electrically Erasable Programmable Read 
Only Memory). L'ensemble de ces elements est relie au microprocesseur par 
un BUS de liaison. A titre d'exemple, une carte a puce comprend dans le 
meilleurs des cas, en utiiisant les nouveaux composants actuellement 
existants, une memoire ROM, une memoire EEPROM de 32 kilooctets ou 

15 kilo bytes, et une memoire RAM de 2 Kilo Bytes. 

Dans un systeme "Java" classique. une application est ecrite sur une 
station ou PC. Son code source est compile dans un pseudocode 
intermediaire, appele "Java Byte Code" ou byte code, qui est independant du 
code machine de la plate-forme utilisee. L'application est ensuite telechargee 

20 sur la plate-forme cible ou plate-forme "Java" classique. L'application 
chargee, constituee d'un ensemble de classes dites classes clients dont les 
methodes ont ete compilees dans le pseudocode, s'appuie sur les interfaces 
de programmation applicatives ou Interface pour la Programmation 
d'Application ou API (Application Programming Interface). Les interfaces de 

25 programmation applicatives permettent d'uniformiser Tinterface utilisateur, de 
controler un editeur, un clavier ou une imprimante par exemple. La machine 
virtuelle d'une plate-forme classique comprend un verifieur de pseudocode, 
un chargeur dynamique de classe, un interpreteur de pseudocode qui 
permet la traduction en code machine et un gestionnaire de securite. 

30 La principale difference entre une machine virtuelle classique et une 

machine virtuelle d'un systeme embarque, appelee machine virtuelle 
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specifique, est due au fait que la machine virtuelle d'un systeme embarque 
est decomposee en deux parties separees. Suivant la figure 4b. la machine 
virtuelle comprend une partie (30) hors de la plate-forme specifique (40), 
appelee machine virtuelle hors plate-forme ("off-platform"), comprenant un 

5 convertisseur (32), et une partie (41) dans la carte constituant la plate-forme 
specifique (40), appelee machine virtuelle embarquee (41) ("on-platform") 
incluant Tinterpreteur de pseudocode. 

Ainsi. dans le cas d'une plate-forme specifique, le programme source 
(21) de I'application est ecrit, compile en pseudocode intermediaire par un 

10 compilateur (22), et verifie par un verifieur (31) de pseudocode intermediaire 
sur une station (20) classique, puis convert! par le convertisseur (32), place 
sur la meme station (20) ou une autre station. Apres un eventuel passage 
par un signeur (34), I'application est ensuite telechargee sur la memoire 
volatile programmable electriquement et eventuellement effagable 

15 electriquement EEPROM (15) de I'objet portable ou plate-forme specifique 
(40). Ce chargement est effectue par un chargeur comportant une partie 
hors plate-forme appelee telechargeur (33) et une partie sur la plate-forme 
specifique appelee chargeur (42). Contrairement a ce qui existe sur une 
plate-forme classique pour une station, la machine virtuelle (41) d'une plate- 

20 forme specifique (40), plac6e en memoire ROM avec le systeme 
d'exploitation (48) (Operating System) ne peut comporter de verifieur de 
pseudocode intermediaire, celui-ci etant trop lourd pour etre stocke et/ou 
execute dans I'objet portable. La plate-forme specifique (40) ne contient pas 
non plus de chargeur dynamique de classes. En effet, pour le domaine 

25 d*application de invention, sur la machine virtuelle (30) hors plate-forme, le 
verifieur (31) verifie que les classes compilees sont bien formees et verifie 
les violations de langage specifiques a la description de la plate-forme 
specifique. Le convertisseur (32) effectue le travail requis pour le 
chargement des classes et la resolution des references. Le convertisseur 

30 effectue la liaison statique des classes, il resout les r§ferences symboliques 
aux classes, methodes et attributs deja presents sur la carte, il repartit le 



wo 01/37085 PCT/FROO/03193 

4 

stockage et cree les structures des donnees pour representor les classes, 
cree les methodes et attributs statiques ou natifs et initialise les variables 
statiques. 

L'environnement d'execution de la plate-forme specifique (Runtime 
5 Environment ou RE) comprend la machine virtuelle embarquee ("on- 
platform") (41) se limitant a un interpreteur. une plate-forme API et les 
methodes dites natives (43) ou encore statiques associees. La plate-forme 
API comprend les API (44) (Application Programming Interface) definissant 
un ensemble de classes, dites classes systeme (45), et les conventions 
10 d'appel par lesquelles une application accede a Tenvironnement d*execution 
(RE) et aux methodes statiques (43). Les methodes statiques (43) executent 
les services d'allocation de memoire, d'entree et sortie, et cryptographique 
de la carte. 

Uinterpreteur de la machine virtuelle embarquee de la carte (41)(on- 

15 platform), sert de support au langage "Java", et lit de fagon sequentielle le 
pseudocode intermediaire, instruction par instruction. Chaque instruction 
standard de ce pseudocode intermediaire est interpretee dans le langage du 
microprocesseur par Tinterpreteur puis executee par le microprocesseur. En 
regie generate, les instructions standards du pseudocode intermediaire 

20 permettent de traitor des fonctions evoluees telle que le traitement 
arithmetique et la manipulations d'objets. La notion d'objet concerne les 
objets informatiques tels que listes, tableaux de donnees ou analogues. Les 
classes dites clients (46) des applications et les classes systemes (45) des 
API sont toutes chargees dans le meme espace memoire et sont gerees par 

25 rintermediaire d'une table de classe (47). 

La machine virtuelle (41) est egalement chargee de gerer les classes 
et objets et de faire respecter les separations ou pare-feu entre les 
applications afin de permettre un partage securise des donnees. appelees 
egalement attributs. variables ou champs (fields). 

30 Dans le cas d'un objet portable de type carte a puce, une application 

d'une plate-forme specifique peut etre activee directement par 
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renvironnement d'execution (RE) lorsqu'une APDU (Application Protocol 
Data Unit) de selection emise par un service ou terminal est regue par la 
carte. 

Afin de restreindre Tacces aux donnees entre les parties de code 

5 partageant le meme espace memoire, une des methodes classiques sur une 
plate-forme classique est basee sur la restriction explicite de visibilite 
declaree dans le code source. Suivant la figure 4c, les methodes (NM1, 
NM2), respectivement (NM3, NM4), et les attributs (NA1, NA2), 
respectivement (NA3, NA4) sont encapsules dans des classes (NCI3), 

10 respectivement (NCI2), qui elles-memes font partie de paquetages 
(Paquetage 1 ), respectivement (Paquetage n) regroupant chacun plusieurs 
classes. Une classe peut etre publique telle que (NCI1 ou NCI2) ou privee 
telle que (NCI3) par rapport a un paquetage, ce qui implique, dans le dernier 
cas, que seules les classes du meme paquetage peuvent acceder a cette 

15 classe. Les methodes (exemple NM2) et les donnees (exemple NA1 ) d'une 
classe (NCI3) peuvent etre privees par rapport a la classe (NM2, NA1), qui 
elle-meme est privee par rapport au paquetage (Paquetage 1), ou publiques 
par rapport au paquetage (par exemple NM1, NA2) ou a la classe (par 
exemple NM4, NA4). Cette restriction de la visibilite permet d'obtenir un 

20 acces flexible entre les differents ensembles de paquetages (Paquetage 1 , 
Paquetage n) stockes dans ie meme espace nom, mais presente quelques 
inconvenients. La plate-forme classique ou specifique supporte mal la notion 
de sous-paquetages. Les classes client d'une application de grande taille 
doivent etre reparties entre differents sous-paquetages qui representent 

25 uniquement pour la machine virtuelle des paquetages differents. Pour 
partager les ressources entre ces sous-paquetages, ces ressources sont 
n6cessairement declarees publiques, les rendant ainsi visibles de tout autre 
paquetage. II est ainsi difficile d'organiser de fagon claire le paquetage 
d'applications differentes pour des applications de grande taille et d'obtenir 

30 des pare-feu entre les applications. 
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Dans le cas de la plate-forme classique, sur una station, le respect 
de la confidentialite des ressources, telle que declaree dans les programmes 
sources, repose sur des verifications dynamiques. Pour effectuer ces 
verifications dynamiques, la machine virtuelle doit posseder toutes les 
informations concernant les declarations de restriction d'acces pour chaque 
classe, methode ou attribut, ce qui ne peut etre possible dans le cas de 
Tespace memoire disponible sur la machine virtuelle embarquee (onplatform) 
utilisant le pseudocode intermediaire ou byte code prelie de la machine 
virtuelle hors plate-forme (offplatform). Dans le cas d'une plate-forme 
specifique d'un objet portable, les restrictions d'acces peuvent se verifier 
statiquement lors de la compilation et peuvent etre verifiees a nouveau par le 
verifieur de la partie hors plate-forme. II est en effet suppose que ce qui est 
charge sur la plate-forme specifique de Tobjet portable est correct, car 
aucune verification ne peut etre effectuee sur la plate-forme specifique du 
fait de la perte des informations lors de la phase de conversion, De plus il 
n'est pas garanti qu'un paquetage ne puisse pas etre etendu ou modifie par 
de nouvelles classes venant de sources etrangeres, ce qui peut detruire 
toute la securite basee sur Tutilisation de paquetages prives. 

Le deuxieme moyen procure par la machine virtuelle d'une plate- 
forme classique est la notion de separation des espaces nom. Avec le 
schema de liaison dynamique d'une plate-forme classique, les classes 
peuvent etre chargees, a partir de repertoires du systeme de fichier local, 
appele "ClassPath" prealablement declare comme constituant Pemplacement 
des classes systemes formant la plate-forme API standard, ou a partir 
d'autres repertoires du systeme de fichier local ou de serveurs eloignes. Les 
classes client d'une application, exterieures au "ClassPath", doivent etre 
chargees par un chargeur de classe specifiquement programme. Cette 
caracteristique est particulierement utilisee pour le chargement des 
applications "Java" par des navigateurs habilit6s "Java". Ainsi, les 
applications venant de differentes sources, sont chargees par des chargeurs 
de classes differents. Pour chaque localisateur, communement appele URL 
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(Uniform Resource Locator), una instance specif ique de classe "chargeur de 
classe d'application" est utilisee. Le nom externe d'une classe est 
rassemblage <Nom Du Paquetage > + <Nonn De La Classe>. Quand une 
classe est chargee, elle est stockee dans une table de classe interne, et une 

5 reference relative au chargeur de classe utilise pour charger cette classe est 
ajoutee en prefixe du nom de paquetage de la classe. Le nom de la classe 
est alors «Reference du Chargeur de Classe> + <Nom Du Paquetage> + 
<Nom De La Classe». Ainsi des classes declarees comme appartenant au 
meme paquetage mais chargees par des chargeurs de classes differents ne 

10 sont pas pergues par la machine virtuelle comme appartenant au meme 
paquetage. 

Lors de la resolution d'une reference, la politique habituelle des 
chargeurs de classe est de rechercher d'abord dans les classes systeme et 
en cas d'echec, de rechercher parmi les fichiers de classe presents a 

15 Templacement ou le chargeur peut charger les classes. Selon ce principe de 
fonctionnement du chargeur, une application ne peut directement acceder 
aux classes clients d*une autre application chargee par un chargeur de 
classes different. Une application peut acceder a toutes les ressources 
publiques des classes publiques du ClassPath, mais les classes du 

20 ClassPath ne peuvent acceder directement aux classes d'une application 
bien qu'elles puissent faire reference a des instances de classes clients de 
Tapplication en les convertissant en un type public defini dans le "Classpath". 
Une application ne peut etendre ou modifier des paquetages de classes 
systeme du Classpath ou de toutes autres applications chargees par des 

25 chargeurs de classes differents. L'utilisation de la separation des espaces 
nom en inserant une reference du chargeur de classe dans le nom de la 
classe. ajoutee au typage complet fourni par le langage "Java", permet de 
procurer un pare-feu efficace entre les applications. Le mecanisme inne de 
separation de nom d'espace permet facilement le chargement de nouvelles 

30 applications. Les applications peuvent echanger des objets par I'entremise 
des classes specifiquement programmees a cette fin et localisees dans le 
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"Classpath". Une application peut utiliser un objet venant d'une autre 
application chargee par un chargeur de classe different, si cat objet peut etre 
change en un type public defini dans le "Classpath". 

Malheureusement ce mecanisme de separation de nom, base sur 
5 une machine virtuelle classique et son processus de liaison dynamique ne 
peut etre effectue sur une plate-forme specifique. La liaison dynamique ne 
peut etre effectuee par la machine virtuelle d'une plate forme specifique, 
celle-ci necessitant un espace memoire permettant le stockage de fichier de 
classe d'une plate-forme "Java" classique, presentant des references non 

10 resolues. Dans une plate-forme specifique. les classes systemes des API et 
les classes clients des applications ne sont pas isolees dans des espaces de 
nommage particuliers. 

L'objet de la presente invention est de proposer une solution 
procurant les avantages de la separation de nom dans le cadre de systemes 

15 embarques possedant une machine virtuelle en deux parties, le schema de 
liaison statique etant effectue par la partie hors plate-forme. 

Dans le contexte de systemes embarques, tels que par exemple les 
terminaux de paiement, multi-application, ii est necessaire d*avoir des pare- 
feu performants entre les applications "Java" fournies par differentes 

20 sources, telles que differents systemes de paiement (Visa, Mastercard...). II 
peut etre utile de permettre une cooperation flexible entre les applications 
venant des differentes sources. Le systeme embarque doit aussi etre 
facilement mis a jour en telechargeant de nouvelles applications ou de 
nouveaux modules utilitaires ou encore des mises a jour sans perturber les 

25 applications deja chargees. 

Un premier but de Tinvention est de proposer un precede de 
chargement permettant d'obtenir des pare-feu robustes entre les applications 
tout en autorisant une cooperation entre les applications et la possibilite de 
faire evoluer les applications ou de charger d'autres applications. 

30 Ce but est atteint par le fait que le precede de chargement 

d'applications sur un systeme embarque selon Tinvention. comprenant un 
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environnement d'execution incluant une machine virtuelle comprenant un 
interpreteur de langage de type pseudocode intermediaire, des interfaces de 
programmation d*application (API), a partir d'une station sur laquelie le code 
source de Tapplication est ecrit, compile en pseudocode par un compilateur , 
5 verifie par un verificateur, convert! par un convertisseur et charge par un 
chargeur, se caracterise en ce que 

- la conversion comprend la realisation de la liaison statique d'une 
pluralite d*ensembtes de paquetages destines a etre stockes dans le meme 
espace nom sur le systeme embarque, appeles modules, en attribuant un 

10 identificateur a chaque module (MID), et un numero de reference a chaque 
classe, a chaque methode et a chaque attribut encapsules dans les classes 
du module, 

- la reference a une methode ou un attribut, dans le pseudocode lie 
d'un module, etant codee sur trois multiplets constitues par un indicateur 

15 indiquant la reference a une classe interne ou externe au module, le numero 
de la classe et soit le numero de la methode soit le numero de Tattribut, 

- les modules charges sont un ou plusieurs modules d'interface de 
programmation d'application, appele Module API, comprenant des classes 
systeme ou des modules de services correspondant chacun a une 

20 application, une reference a une classe externe etant systematiquement 
interpretee par la machine virtuelle comme une reference a un module 
dlnterface de programmation d'application. 

Selon une autre particularity, le chargement des modules sur le 
systeme embarque comprend la memorisation d*une part d'au moins un 

25 tableau de representation des modules, le numero associe. par le lieur 
compris entre 0 et n, ^ un module constituant Tindex dudit module dans le 
tableau, et d*autre part d'une table memorisant I'association de Tindex du 
tableau de representation a Tidentificateur (MID) dudit module, ledit tableau 
et la table etant en memoire programmable non volatile, une reference 

30 externe a un module externe dans le pseudocode etant interpretee par 
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rinterpreteur de la machine virtuelle comme constituant un index d'acces au 
module equivalent a celui du tableau des modules. 

Selon une autre particularite, le chargement comprend la 
memorisation, pour chaque module, d'un tableau de representation de ses 
5 classes, comprenant une reference a Tindex de son module et, pour chaque 
classe, un tableau de representation des attributs et des methodes. 

Selon une autre particularite, les modules sont references dans un 
tableau de modules unique, les classes systeme sont contenues dans un 
module API unique, toute reference a une classe externe dans le 
10 pseudocode differente de n sera interpretee par la machine virtuelle comme 
une reference audit module API. 

Selon une autre particularite, les classes etant declarees publiques, 
ou en paquetage prive, les attributs et methodes etant declares proteges, en 
paquetage privee ou en classe privee, la numerotation des classes s'effectue 
15 suivant Tordre classes publiques puis classes en paquetages prives, la 
numerotation des attributs ou methodes est effectuee par le convertisseur 
suivant Tordre attribut ou methode public, protege, en paquetage prive et en 
classe privee. 

Selon une autre particularite, les classes systeme sont contenues 
20 dans plusieurs modules API chargeables separement, le chargeur maintient 
dans la memoire non volatile programmable deux tableaux de representation 
des modules et deux tables d'association MID/IMi correspondantes. Tun pour 
les modules API et Tautre pour les modules non-API, le chargeur chargeant 
les modules dans Tun des deux tableaux selon la nature du module specifie 
25 dans Tentete de celui-ci, toute reference externe d'un module du tableau de 
module etant interpretee comme une reference a Tindex du module API. 

Selon une autre particularite, la liaison statique d'un module est 
effectuee de telle sorte que la reference a une classe externe a un module 
non API dans le pseudocode intermediaire est un index dans un tableau de 
30 I'entete du module, dont chaque entree est un identificateur (MID) d'un 
module API reference, le chargement dudit module sur la plate-forme cible 
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comprenant le remplacement de ladite reference par le numero de Tindex 
du module API obtenu a partir de Tidentificateur (MID) de la table 
d'association des modules API. 

Un autre but de Tinvention est de proposer un systeme embarque 
5 correspondant. 

Ce but est atteint par le fait que le systeme embarque selon 
rinvention, comprenant une machine virtuelle et une plate-forme API incluant 
des interfaces de programmation d'application, une memoire non volatile 
fixe, une memoire non volatile programmable ou modifiable, et une memoire 

10 Vive, se caracterise en ce que la memoire non volatile programmable 
comprend au moins un module API comprenant des classes systeme et des 
modules de services, au moins un tableau de representation des modules, 
dans lequel les modules sont indexes et une table associant Tindex d'un 
module du tableau de representation a Tidentificateur dudit module, chaque 

15 module comprenant un tableau de representation des classes, dans lequel 
les classes sont indexees et dans lequel chaque classe presente une 
reference a Tindex de son module, chaque classe comprenant un tableau de 
representation des attributs et des methodes, dans lesquels les attributs et 
methodes sont indexes, la reference a une methode ou un attribut etant 

20 codee sur au moins trois multiplets correspondant a une reference a une 
classe interne ou externe au module, une reference externe au module 
constituant I'index du module API dans le tableau de module, un numero de 
classe correspondant a Tindex de la classe dans la table de representation 
des classes du module, et un numero de methode ou d'attribut 

25 correspondant a I'index de la methode ou de I'attribut dans le tableau de 
representation des methodes ou attributs de la classe du module. 

Selon une autre particularite, le systeme embarque comporte des 
moyens de comparaison du premier multiplet des trois multiplets de codage 
de reference a une methode ou a un attribut avec une valeur determinee n 

30 pour decider s'il s'agit d'une classe interne ou externe. . 
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Selon une autre particularite, le systeme embarque comprend un 
module principal comprenant le programme principal du systeme. 

Selon une autre particularite, les classes sont indexees suivant 
I'ordre classes publiques puis classes en paquetages prives, et les attributs 
ou methodes suivant Tordre attribut ou methode public, protege, en 
paquetage prive et en classe privee. 

Selon une autre particularite, la memoire non volatile programmable 
comprend plusieurs modules API comprenant des classes systeme, deux 
tableaux de representation des modules, Tun pour les modules API et Tautre 
pour les modules non-API et le module principal, et deux tables d'association 
MID/IMi correspondant chacune a un tableau de representation des 
modules., 

Selon une autre particularite, le systeme embarque comprend une 
classe gestionnaire d'acces "Access manager" d*un module API comprenant 
une methode permettant de creer une instance d'un module de service, par 
rintermediaire du module principal, ladite classe presentant une protection lui 
interdisant d'avoir plus d'une instance. 

Un autre but de Tinvention est de proposer un precede d'execution 
d'une application presente sur un systeme embarque multi-application. 

Ce but est atteint par le fait que le precede d'execution d'une 
application d'un systeme embarque multi-application, comprenant un 
environnement d'execution incluant une machine virtuelle comprenant un 
interpreteur de langage de type pseudocode intermediaire, et des interfaces 
de programmation d*applications (API), se caracterise en ce que, iors de 
Texecution du pseudocode intermediaire d'un module de service, 
correspondant a une application, referencee dans un tableau de module, la 
reference a une methode ou un attribut dans le pseudocode, codee sur au 
moins trois multiplets correspondant a une reference a une classe interne 
ou externe au module, un numero de classe et un numero de methode ou 
d'attribut, une reference externe au module est interpretee par la machine 
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virtuelle comme une reference a Tindex d'un module API du tableau du ou 
des modules API. 

Selon une autre particularite, sur reception d'une demande 
d'execution d'un module de service presentant un identificateur, 
Tenvironnement d'execution accede a la classe d'entree d'un module 
principal comprenant le programme principal du systeme, le module principal 
installe une instance d'une classe speciale "Access Manager", d'un module 
API, gerant Tacces a un module de service et utilise une methode de cette 
classe permettant de creer une instance de la classe d'entree du module de 
service demandee, par I'intermediaire d'une table d'association de 
I'identificateur a I'index du module dans un tableau dans lequel le module est 
reference, instance etant retournee par la methode au programme principal. 

D'autres particularites et avantages de la presente invention 
apparaitront plus clairement a la lecture de la description ci-apres faite en 
reference aux dessins annexes dans lesquels : 

- la figure 1 represente de fagon schematique les differents elements 
necessaires pour le chargement d'un objet portable selon un premier mode 
de realisation ; 

- la figure 2 represente de fagon schematique les differents elements 
necessaires pour le chargement d'un objet portable selon un deuxieme 
mode de realisation ; 

- la figure 3 represente la representation interne d'un module ; 

- la figure 4a represente le schema classique d'une carte a puce ; 

- la figure 4b represente le systeme necessaire a la constitution 
d'une machine virtuelle embarquee sur une carte a puce selon I'art anterieur; 

- la figure 4c represente la structure des classes d'une application. 
Le precede sera decrit, en liaison avec les figures 1 a 3, de maniere 

non limitative, dans le cas de la mise en oeuvre de invention dans un 
systeme embarque, par exemple de type specifique constitue par une carte 
a puce ou un objet portable similaire. La designation byte code ou 
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programme de type byte code recouvre tout pseudocode ou programme 
intermediaire. 

L'objet porteible constitue par exempie une carte k puce et pr^sente 
une structure similaire de celle decrite prec6demment en reference aux 
figures 4a et 4b, et comprend notamment une memoire RAM, ROM et 
EEPROM. La plate-forme specifique (60) et une station classique (80) sont 
representees sur la figure 1. La plate-forme specifique (60) poss^de en 
ROM, un environnement d'execution (RE) comprenant des API (62) et une 
machine virtuelle (61) embarquee ("onplatform"). La plate-forme specifique 
(60) est representee sur la figure 1, comme comprenant I'ensemble des 
memoires ROM et EEPROM. II est ^ noter que la plate-forme specifique (60) 
designe plus particulierement I'environnement d'ex§cution (RE) et les 
Elements presents en memoire EEPROM. L'objet portable possede en ROM 
un systeme d'expioitation (Operating System) (63). Les API (62), presentes 
en memoire ROM, constituent les API de base de la plate-forme API, 
chargees avec la machine virtuelle embarquee pour le fonctionnement de 
celle-ci. 

La partie (90) hors objet portable de la machine virtuelle comprend 
un verifieur (91) de pseudocode intermediaire, un convertisseur (92) et 
6ventuellement un signeur (94). Le signeur delivre une signature pour valider 
le passage par le verifieur et le convertisseur. Cette signature sera verifiee 
par l'objet portable au moment du chargement. Le chargement en EEPROM 
d'applications ou de nouvelles API pour completer les API de base s'effectue 
par un chargeur qui peut etre compose de deux parties, une partie hors objet 
portable pouvant etre installee dans la machine virtuelle hors objet portable 
(90), appelee telechargeur (93), et une partie sur la plate-forme specifique, 
appel§e chargeur (68). 

Selon un premier mode de realisation, la plate-forme specifique (60) 
comprend deux modules speciaux, un module API (65) et un module 
principal (66). Les autres modules sont appeles modules de services (67). 
Chaque module correspond a un ensemble de paquetages qui sera stocke 
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dans le meme espace nom. La plate forme API deslgne les API de base (62) 
et I'ensemble des classes syst§me qui d6finissent le module API (65) ou 
module de la plate-forme API. Le module principal comprend la classe 
principale definlssant le programme principal. Chaque module, except^ le 
module API (65), possede une classe unique, particuliere, appelee "Entry 
Class", qui constitue le point d'acces au module. Pour le module principal, 
cette "Entry Class" est la classe principale (CP), celle qui contient une 
methode statique appelee "main". Pour les modules de services, c'est une 
classe avec seulement un constructeur sans paramdtres et implementant 
une interface publique sp§clale, appelee "service" definie dans la plate-forme 
API. Le chargement d'une application correspond au chargement d'un 
module de service. Chaque module regoit un identificateur sp6cifique. Un tel 
identificateur, qui est appele MID, peut par exemple etre un nombre, une 
chaTne de caracteres, ou un tableau. A titre d'exemple, I'identificateur est 
une ChaTne de caracteres. 

Quand lis sont charges dans la plate-forme, par des mecanismes de 
tel§chargement distincts de la machine virtuelle de la plate-forme specifique, 
les modules regoivent un nombre, compris entre 0 et n. Ainsi, selon cette 
convention, n+1 modules au plus peuvent etre presents sur la plate-forme 
specifique. Le t6l6chargeur (93) de module avec le chargeur (68) maintient, 
lors du chargement de nouveaux modules de service, un tableau (TRM) (69) 
de representation des modules. Le numero associe k un module est I'index 
(IM) de ce module dans le tableau. Le chargeur (68) maintient egalement 
une table (70) associant I'index (IM) k I'identificateur (MID) de chaque 
module. Le module API regoit systematiquement pour Index IMo le num6ro 0, 
et le module principal pour index IMi le numero 1. L'entete (header) de 
chaque module comprend un indicateur permettant au chargeur de 
determiner la nature du module, "principal", modules "de service" ou module 
"API". 

Le chargeur (68) ne peut charger que les modules autorises a 
resider sur I'objet portable, c'est k dire uniquement les modules presentant 
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une signature connue de I'objet portable. Le chargeur (68) comporte done 
des moyens de verifier la signature d'un module regu, de la comparer avec la 
signature connue de I'objet portable et en cas de comparaison negative de 
bloquer le chargement. 

De maniere classique, tel que defini dans I'art anterieur cite 
pr6cedemment, le programme source (81) d'une application est ecrit puis 
compile par un compilateur (82) et ensuite verifie par le verifieur (91). 

La liaison statique, realisee dans le convertisseur (92) par un 
composant dit lieur (linker) du convertisseur, va resoudre des references 
symboliques en attribuant 

- un num§ro (NCI) a chaque classe d'un module, 

- un numero (NM) pour chaque methode dans une classe et 

- un numero (NA) pour chaque attribut dans une classe. 

Chacun de ces numdros (NCI, NM, NA) est compris entre 0 et n et 
peut ainsi etre represents sur un byte ou multiplet. A titre d'exemple, chacun 
de ces nombres sera compris entre 0 et 255 (n=255). La reference a une 
methode ou un attribut d'une classe sera ainsi codee dans le pseudocode lie 
des m6thodes du module sur deux multiplets (bytes) ou octets. Le 
pseudocode contiendra ces deux multiplets < NCI> pour la classe et < NA> 
pour un attribut ou <NM> pour une methode. 

Suivant la figure 3, la representation interne d'un module API (65), 
d'un module principal (66) ou d'un module de service (67), contiendra un 
tableau (TRC) de representation de classes ; le numero (NCI) associe par le 
lieur, hors du systeme embarque, a chaque classe est I'Index (ICi) de la 
representation de cette classe dans le tableau (TRC). Chaque classe 
pr6sente egalement une reference a I'index (IMi) de son module. De la 
m§me maniere, la representation de chaque classe contient un tableau des 
representations de methodes (TRMe) et un tableau de representation des 
attributs (TRA) appartenant a la classe. Le numero (NM), associe par le lieur, 
hors du systeme embarque, a chaque m6thode est I'index (IMi), de la 
representation de cette methode dans le tableau (TRMe), et le numero (NA), 
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associe par le lieur, hors du systeme embarque, a chaque attribut est Tindex 
(lAi). de la representation de cet attribut dans le tableau (TRA). 

A titre d'exemple, nous voulons qu'un module puisse referer 
uniquement a ses propres classes et aux classes systemes de la plate-forme 

5 API, les classes systeme correspondant aux classes du "ClassPath" d'une 
plate-forme classique. Selon Tinvention, pour permettre la distinction entre 
une reference a une classe interne au module et la reference a une classe 
systeme (ou externe au module), un indicateur interne (II) ou externe (IE) est 
ajoute a la reference a une methode ou a un attribut. La reference resolue 

10 est alors codee sur trois multiplets : <IE/II> <NCI> < NM> ou <IE/II> <NCI> 
<NA> 

Selon une convention posee, pour la valeur n du premier multiplet 
<IE/II> la valeur 255 d'apres notre exemple, correspond a une reference 
interne <ll> au module et toute autre valeur pour le premier multiplet 

15 correspond a une reference externe <IE> au module. 

Le lieur du convertisseur (92) de la machine virtuelle hors objet 
portable (90), relie en premier le module API (65), qui ne possede pas de 
references externes <IE> dans son pseudocode, et produit une implantation 
ou agencement, correspondant a un plan de noms symboliques de ses 

20 classes et de leurs methodes et attributs. Lors de la mise en liaison des 
autres modules, cette implantation sera utilisee pour etablir les references 
externes a des classes systemes du module API (65). 

Suivant notre convention des multiplets (bytes) encodant les 
references, il peut y avoir au plus 256 (n+1) classes dans le module API et 

25 256 classes dans chaque module supplementaire. 

Lors de Texecution d'un module de service, quand la machine 
virtuelle (61) trouve une reference a une methode <NM> ou un attribut <NA> 
dans le pseudocode, en connaissant la classe <NCI> ou se trouve cette 
reference, elle peut retrouver directement Tindex <IMi> du module concerne, 

30 celui-ci correspondant a la reference externe (IE) ou interne (II). Toute 
reference externe <IE> dans le pseudo code d'un module de service sera 
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systematiquement interpretee par la machine virtuelle comme une reference 
au module API. Un module de service ou le module principal ne peut pas 
referer aux classes de tout autre module excepte celles du module API, Les 
classes systemes de ce module API ne peuvent pas referer aux classes d'un 
5 module de service ou du module principal. La reference interne a une classe 
d'un module, correspondant a la valeur n pour le premier multiplet, ne 
necessite aucune connaissance a priori de Tespace nom qui sera attribue au 
module. Le fait de ne pas definir a priori d'espace de nommage fixe lors de la 
phase de conversion permet d'accelerer la resolution des references et de 

10 determiner Tespace de nommage d'un module lors du chargement, 
posterieurement a la phase de conversion. La machine virtuelle, lors de 
rinterpretation d'une reference a un attribut ou a une methode dans le 
pseudocode, utilise les trois index <IE/II> <NCI> < NM> ou <IE/II> <NCI> 
<NA> en cascade. L'espace memoire du module etant determine, rindex 

15 <NCI> determine Tentree desiree dans le tableau des classes (TRM) du 
module, puis le dernier index < NM> ou <NA> donne Tentree desiree dans le 
tableau des methodes (TRMe) ou le tableau des attributs (TRA). 

Le module API comprend une classe speciale (64), appelee classe 
"gestionnaire d'acces" ou "Access Manager", qui comprend une methode 

20 native (getServicelnstance) dont le role est de rendre un objet instance de la 
classe d'entree du module de service demande, a partir de Tidentificateur 
(MID) du module. Cette methode utilise la table (70) d'association MID/lmi 
pour connaitre I'index du module demande dans le tableau de module (69) 
puis cree une instance de la classe d'entree de ce module, instance qui est 

25 retournee par la methode. Selon I'invention la classe "Access Manager" (64) 
est protegee par construction par une methode consistant a interdire que 
cette classe ait plus d'une instance. Cette methode (getServicelnstance) 
appartient au programme principal contenu dans le module principal. Le 
module principal qui sera active en premier a utilisation de I'objet portable 

30 cree une instance et une seule de la classe "Access Manager", ce qui lui 
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permet d'utiliser la methode getServicelnstance, mais interdit a tout autre 
service de creer une autre instance pour utiliser cette methode. 

En fonctionnement, de la meme fagon que sur une plate-forme 
classique, Tenvironnement d'execution (RE) accede a la classe d'entree (EC) 
5 du module principal et active sa methode d'entree (main). Le module 
principal, etant le premier active, precede a Tinstallation d'une instance de la 
classe "Access manager" avant que tout autre service le fasse. puisque pour 
activer d'autres services, le module principal doit deja posseder une telle 
instance de la classe acces. 

10 Ce simple dispositif permet de reproduire Teffet de protection lie au 

concept d'espace de nommage d'une plate-forme classique. Le simple fait 
de charger un module de service dans le tableau des modules et que la 
presence dans le pseudocode de toutes reference externe soit interpretee 
par la machine virtuelle comme une reference au module API, rend ce 

15 module completement inaccessible directement par les autres modules, 
creant ainsi un pare-feu total. 

Ce premier mode de realisation permet d'apporter les avantages de 
pare-feu procure par la separation des espaces nom dans le contexte d'une 
machine virtuelle en deux parties. Toutefois ce mode de realisation se revele 

20 peu flexible et presente deux inconvenients. 

Premi^rement, il empeche toute modification ou extension des 
classes systemes avec des modules deja prelies. Une architecture "Java" 
classique permet de modifier et d'etendre les classes de la plate-forme API 
sans avoir d'impact sur les classes deja compilees de modules 

25 supplementaires. Mais dans le mode de realisation decrit precedemment, 
toute modification des classes systeme, meme invisible pour des modules 
etrangers, modifierait Tagencement de la plate-forme API et necessiterait de 
modifier le pseudocode prelie de chaque module deja li§ avec une version 
anterieure de I'agencement et en consequence Tinterpreteur. 

30 Deuxi^mement, les modules preli6s sont supposes etre portables 

entre les diff6rentes plates-formes ou terminaux embarqu§s, ce qui impose 
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que chacune de ces plates-formes doit avoir le meme agencement que la 
plate-forme API, ce qui interdit Tutilisation de toute extension proprietaire. 

Afin de remedier partiellement a ces inconvenients, une variante du 
premier mode de realisation, consiste a imposer que, dans la numerotation 
de rimplantation, les classes publiques viennent en premier avant les 
classes en paquetage prive. De plus, les methodes publiques ou les attributs 
publics viennent avant ceux qui sont proteges et ceux qui sont en 
paquetages prives et en classes privees. Ceci permet d'ajouter librement de 
nouvelles classes publiques dans le module API (65). 

La figure 2 represente un deuxieme mode de realisation permettant 
revolution de la plate-forme API. La plate-forme API est constituee de 
plusieurs modules API (100) pouvant etre charges separement, au lieu d'etre 
constituee d'un module API unique. 

Dans ce mode de realisation, le telechargeur (93) et la machine 
virtuelle partagent deux tableaux de modules et deux tables d'association 
MID/index au lieu d'un de chaque, un tableau (101) et une table 
d'association (102) pour les modules API et un tableau (103) et une table 
d'association (104) pour les modules non-API, correspondant au module de 
service (67) et au module principal (66). 

Chaque module presente dans son entete un indicateur indiquant sa 
nature "Service" ou "API" permettant au chargeur de charger le module dans 
le tableau (101) de modules API ou dans le tableau (103) de modules non- 
API. Get indicateur est place dans Tentete du module lors de la phase de 
compilation par le convertisseur. 

Le pare-teu constitue par la separation de Tespace nom est present 
uniquement entre les modules non-APL Toute reference externe a un 
module de service sera interpretee par I'interpreteur de la machine virtuelle 
embarquee comme un index du tableau du module API. 

Les modules non-API seront numerotes de 0 jusqu'a 255 au plus, 
dans I'exemple ou n=255. 0 est par exemple Tindex du module principal (66). 
Les modules API (100) seront numerotes de 0 a 254 au plus. 0 etant par 
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exemple Tindex d'un module dit API primaire, qui contient toutes les 
methodes natives. Conformement a la convention decrite precedemment, 
ceci permet au plus, 255 (n) modules differents dans la plate-forme API. La 
reference a une methode ou attribut dans le pseudocode est : 
5 « IE/II> <NCI > < NM/NA» 

La valeur 255 (n) pour le premier multiplet (byte) indiquera, comme 
dans le premier mode de realisation, une reference interne au module. 
Chaque valeur differente de 255 indiquera une reference externe a un 
module specifique (100) du tableau de module API de la plate-forme API. 

10 Apres la realisation de la liaison par le lieur (92) hors plate-forme, le 

pseudocode d'un module comporte une entete presentant un tableau de 
modules references utilise pour lier le module courant. Ce tableau de 
modules references comprend au plus 255 entrees, chaque entr§e 
correspondant a Tidentificateur (MID) d'un module API (100). Le premier 

15 multiplet (byte) d*une reference externe dans le pseudocode sera alors un 
index dans ce tableau. Lors du chargement sur la plate-forme d'un module 
non API (67, 66), les numeros d'index associes a des modules API (100) 
seront connus et ainsi chaque premier octet d'une reference externe sera 
remplace par le numero d'index associe au module API refere en utilisant la 

20 table (102) d'association MID/IMi des modules API (100). Ce remplacement 
est la seule operation de liaison realisee sur la plate-forme specifique, par le 
chargeur (68), la table (102) d'association MID/IMi etant utilisee uniquement 
pour realiser cette operation de liaison. 

A titre d'exemple, supposons que dans le pseudocode d'un module 

25 de service 'TEST", nous avons la reference a un numero de m6thode 5 du 
numero de classe 7 d'un module API dont Tidentificateur (MID) est "POO". 
Supposons de plus que "FOO" est I'identificateur du quatrieme module API 
externe trouve reference dans le module de service "TEST". La reference 
dans le pseudocode est alors constitute par les trois valeurs suivantes : 3, 7, 

30 5. 
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Le numero 3 correspond au quatrieme index dans le tableau de 
modules references present dans I'entdte du module, venant en tete du 
pseudocode, la valeur de cette entree etant I'identificateur (MID) "FOO". 
Supposons que lors du chargement du module API "FOO. I'index Interne 34 
lui ait et§ attrlbue sur la plate-forme cible dans la table d'assoclation (102) 
des modules API. Alors, le chargeur (68), a I'aide de la table d'assoclation 
(102) modifie la reference dans le pseudocode du module de service TEST' 
pour devenir : 34, 7, 5. 

Lors de I'ex^cution du pseudocode d'un module, une reference 
externe au module est syst6matiquement interpretee par la machine virtuelle 
comme une entree dans la table de module API. Les modules du tableau de 
module non API restent invisibles les uns des autres ainsi que par rapport 
aux modules API. Ce simple dispositif permet de reproduire I'effet de 
protection lie au concept d'espace de nommage d'une plate-forme classique. 
Le simple fait de charger un module dans le tableau de module non API le 
rend compl^tement inaccessible directement par les autres modules, creant 
ainsi un pare-feu total. 

Le tableau (101) de modules API comprend un module specifique 
(105), appele module "API Access" qui comprend une methode native 
(getServicelnstance) dans une classe "gestionnaire d'acces" ou "Access 
Manager" dont le role est de rendre un objet instance de la classe d'entree 
du module de service demande. Cette methode utilise la table (104) 
d'assoclation MID/IMi pour connaTtre I'index du module de service demand^ 
dans le tableau (103) de modules non-API puis cree une instance de la 
classe d'entree de ce module qui est retournee par la methode au 
programme principal. La politique de securite pr§conis6e est de faire de la 
classe "Access Manager" une classe protegee dont le constructeur et les 
m6thodes sont declares proteges. De plus, le module "API Access" (105) 
comprend une protection consistant a interdire que la classe "Access 
Manager" alt plus d'une instance. Cette methode est reservee au programme 
principal contenu dans le module principal (66). Le module principal qui est 
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active en premier cree une instance du module Access manager, ce qui lui 
permet d'utiliser la methode getServicelnstance, mais interdit a tout autre 
service de creer une autre instance pour utiliser cette methode. Ainsi le 
module principal pourra creer des instances de services. 

Plusieurs methodes peuvent etre utilisees pour obtenir cette 
protection consistant a interdire que la classe "Access manager" n'ait qu'une 
seule instance. Le constructeur de la classe peut par exempie bloquer la 
demande de creation d'instance lorsqu'il en existe deja une et lance une 
exception de securite. En fonctionnement, I'environnement d'execution (RE) 
accede a la classe d'entree du module principal (66) et active sa methode 
d'entree (main). Le module principal etant le premier active, precede a 
rinstallation d'une instance de la classe "Access Manager" du module 
Access avant que tout autre service le fasse. 

Afin de permettre a un module de service d'activer un autre module 
de service, cette politique stricte de securite peut etre modifi6e en ajoutant a 
la classe "Access Manager" du module API Access (105) des classes 
publiques permettant a tout module d'y faire des requetes. Ces requetes 
seront trait6es et controlees par Tunique instance creee par le module 
principal. Ces classes publiques comprennent notamment une methode 
statique permettant d'obtenir I'unique instance. Un module ayant acces ^ 
robjet instance de la classe "Access Manager" pourra activer un autre 
module de service et Tutiliser, mais il ne pourra pas referencer directement 
ses classes, ses methodes ou ses attributs sans etre reper6 par la machine 
virtuelle, etant donne que toute reference externe dans le pseudocode est 
une reference interne au module ou une reference externe a un module API. 

Pour une realisation simple de cette solution, il est necessaire de ne 
pas avoir de references circulaires parmi les modules API. En consequence, 
la fermeture transitive de la relation "refere a"("refers to") doit etre un ordre 
strict partiel sur un jeu de modules. II est ainsi possible de concevoir dans le 
lieur du convertisseur (92) une strat6gie simple pour lier et produire 
I'agencement des modules API en traitant en premier les elements 
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minimums non encore lies. II est possible de suivre la meme strategie basee 
sur un ordre partiel pour le telechargement des modules API, de telle sorte 
que lors du telechargement d'un module M, tous les modules auquel il se 
refere aient deja ete telecharges et qu'un numero leur aient ete assigne. 
5 Uassignation de Tindex interne sur la plate-forme cible se fait par le chargeur 
(68) de module en assignant Tindex n-1 a TAPI d'ordre n. Un module API ne 
peut referer a un autre API module d'index superieur. 

Uutiiisation de ce systeme de double tableau de modules (101, 103) 
et de table d'association (102, 104), permet de remplacer facilement un 

10 module API unique par plusieurs modules API chargeables separement. Le 
remplacement d'un module API unique par plusieurs modules API permet 
d'etendre la plate-forme API avec de nouveau modules, sans modifier 
rassemblage des modules deja charges, sans changer la securite offerte par 
les pare-feu. Bien entendu, ces deux modes de realisation ne sont pas 

15 compatibles ; les modules doivent etre prelies specifiquement pour Tun ou 
rautre des modes de realisation, le pseudocode relatif a un des modes de 
realisation n'etant pas portable sur une plate-forme Implementant I'autre 
mode de realisation. De plus, Tinterpreteur de la machine virtuelle differe 
d'un mode de realisation a I'autre. Dans le premier mode de realisation, la 

20 machine virtuelle ne manipule qu'un seul tableau et une table d'association : 
le premier multiplet d'une reference sera interprets par la machine virtuelle 
comme une reference interne pour toute valeur egale a n et comme une 
reference externe a I'unique module API pour toute valeur differente de n. 
Dans le second mode de realisation, la machine virtuelle manipule deux 

25 tableaux et deux tables d'association : le premier multiplet d'une reference 
dans le pseudocode sera interprete par la machine virtuelle comme une 
reference interne au module pour toute valeur egale a n et toute valeur 
differente de n sera prise directement comme index dans le tableau de 
module API. Dans les deux modes de realisation I'interpreteur de la machine 

30 virtuelle comprend des moyens de comparaison du premier multiplet des 
trois multiplets de codage d'une reference a une methode ou a un attribut 
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avec une valeur determinee n pour decider s1l s'agit d'une classe interne ou 
externe au module. La numerotation des modules API peut etre determinee 
au moment du chargement pour fixer definitivement et de maniere tres 
simple les references externes dans le pseudocode. 

Les memos mecanismes sont utilises pour manier les deux types de 
modules, bien que la fagon dont ils sont utilises et la securite procuree soient 
tout a fait differentes. Tout module peut acceder librement aux modules API 
puisque leurs classes sont des classes systeme. Uutilisation de I'approche 
modulaire est utilisee avec les modules services pour procurer un pare-feu 
rigoureux pour proteger ces modules de tout acces direct. 

Le precede selon Tinvention peut etre realise sur tous types d'objet 
portable presentant de faibies ressources, tel que par exemple, 16 Ko de 
memoire ROM, 8ko de memoire EEPROM et 256 k de memoire RAM, 

D'autres modifications a la portee de I'homme de metier font 
egalement partie de Tesprit de Tinvention. 
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REVENDICATIONS 

1. Procede de chargement d'applications sur un systeme embarque 
comprenant un environnement d'execution incluant une machine virtuelle 

5 comprenant un interpreteur de langage de type pseudocode intermediaire, 
des interfaces de programmation d*application (API), a partir d'une station 
sur laquelle le code source de Tapplication est ecrit, compile en pseudocode 
par un compilateur (82), verifie par un verificateur (91), convert! par un 
convertisseur (92), et charge par un chargeur (93, 68). caracterise en ce que 

10 - la conversion comprend la realisation de la liaison statique d'une 

pluralite d'ensembles de paquetages destines a etre stockes dans le meme 
espace nom sur le systeme embarque, appeles modules, en attribuant un 
identificateur a chaque module (MID), et un numero de reference a chaque 
classe (NCI), a chaque methode (NM) et a chaque attribut (NA) encapsules 

15 dans les classes du module, 

- la reference a une methode ou un attribut, dans le pseudocode lie 
d'un module, etant codee sur trois multiplets constitues par un indicateur 
indiquant la reference a une classe interne (II) ou externe (IE) au module, le 
numero de la classe (NCI) et soit le numero de la methode (NM) soit le 

20 numero de I'attribut (NA), 

- les modules sont un ou plusieurs modules d'interface de 
programmation d'application comprenant des classes systeme ou des 
modules de services correspondant chacun a une application, une reference 
(IE) a une classe externe etant systematiquement interpretee par la machine 

25 virtuelle comme une reference a un module d'interface de programmation 
d'application. 

2. Procede de chargement d*applications sur un systeme embarque 
selon la revendication 1 , caracterise en ce que le chargement des modules 
sur le systeme embarque comprend la memorisation d'une part d'au moins 

30 un tableau (69, 101, 103) de representation des modules, le numero (IMi) 
associe. par le lieur compris entre 0 et n, a un module constituant llndex 
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dudit module dans le tableau, et d'autre part d'une table (70, 102, 104) 
memorisant rassociation de Tindex du tableau de representation a 
ridentificateur (MID) dudit module, ledit tableau et la table etant en memoire 
programmable non volatile, une reference externe (IE) a un module externe 
dans le pseudocode etant interpretee par Tinterpreteur de la machine 
virtuelle comme constituant un index d'acces au module equivalent a celui 
du tableau des modules. 

3- Precede de chargement d'applications sur un systeme embarque 
selon la revendication 2, caracterise en ce que le chargement comprend la 
memorisation, pour chaque module, d'un tableau de representation (TRC) de 
ses classes, comprenant une reference a I'index de son module et, pour 
chaque classe, un tableau de representation (TRA) des attributs et des 
methodes (TRMe). 

4. Precede de chargement d'applications dans un systeme 
embarque selon la revendication 2, caracterise en ce que les modules sent 
references dans un tableau de modules unique, les classes systeme sent 
contenues dans un module API unique, toute reference a une classe externe 
dans le pseudocode differente de n sera interpretee par la machine virtuelle 
comme une reference audit module API. 

5. Proc6de de chargement d'applications dans un systeme 
embarque selon la revendication 4, caracterise en ce que les classes 6tant 
d6clarees publiques, ou en paquetage prive. les attributs et methodes etant 
declares proteges, en paquetage privee ou en classe privee. la numerotation 
des classes s'effectue suivant Tordre classes publiques puis classes en 
paquetages prives, la numerotation des attributs ou methodes est effectuee 
par le convertisseur (92) suivant I'ordre attribut ou methode public, protege, 
en paquetage prive et en classe privee. 

6. Precede de chargement d'applications sur un systeme embarque 
selon la revendication 2, caracterise en ce que les classes systdme sent 
contenues dans plusieurs modules API chargeables s6par6ment, le 
chargeur (68) maintient dans la memoire non volatile programmable deux 



wo 01/37085 



28 



PCT/FROO/03193 



tableaux de representation des modules et deux tables d'association MID/lmi 
correspondantes, Tun pour les modules API et Tautre pour les modules non- 
API, le chargeur chargeant les modules dans Tun des deux tableaux selon la 
nature du module specifie dans Tentete de celui-ci, toute reference exteme 
5 d'un module du tableau de module etant interpretee comme une reference a 
Tindex du module API, 

7. Precede de chargement d'applications sur un systeme embarque 
selon la revendication 6. caracterise en ce que la liaison statique d'un 
module est effectuee de telle sorte que la reference a une classe exteme a 

10 un module non API dans le pseudocode Intermediaire est un index dans un 
tableau de Tentete du module, dont chaque entree est un identificateur (MID) 
d'un module API reference, le chargement dudit module sur la plate-forme 
cible comprenant le remplacement de ladite reference par le numero de 
rindex du module API obtenu a partir de I'identificateur (MID) de la table 

15 d*association MID/IMi des modules API. 

8. Systeme embarque comprenant une machine virtuelle et une 
plate-forme API incluant des interfaces de programmation d'application, une 
memoire non volatile fixe, une memoire non volatile programmable ou 
modifiable, et une memoire vive, caracterise en ce que la memoire non 

20 volatile programmable comprend au moins un module API comprenant des 
classes systeme et des modules de services, au moins un tableau de 
representation des modules (TRM), dans lequel les modules sont indexes et 
une table (70, 104) associant Tindex (IM) d'un module du tableau de 
representation a I'identificateur (MID) dudit module, chaque module 

25 comprenant un tableau de representation des classes (TRC), dans lequel les 
classes sont indexees et dans lequel chaque classe presente une reference 
a rindex (IM) de son module, chaque classe comprenant un tableau de 
representation des attributs (TRA) et des methodes (TRMe), dans lesquels 
les attributs et methodes sont indexes, la reference a une methode ou un 

30 attribut etant codee sur au moins trois multiplets (bytes) correspondant a une 
reference a une classe interne (II) ou externe (IE) au module, une reference 
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externe au module constituant ['index du module API dans le tableau de 
module, un numero de classe (NCI) correspondant a Tindex de la classe 
dans la table de representation des classes du module, et un numero de 
methode (NM) ou d'attribut (NA) correspondant a Tindex de la methode ou 
5 de rattribut dans le tableau de representation des methodes ou attributs de 
la classe du module. 

9. Systeme embarque selon la revendication 8, caracterise en ce 
qu'il comporte des moyens de comparaison du premier multiplet des trois 
multiplets de codage de reference a une methode ou a un attribut avec une 

10 valeur determinee n pour decider s'il s'agit d'une classe interne ou externe. 

10. Systeme embarque selon la revendication 8, caracterise en ce 
qu*il comprend un module principal comprenant le programme principal du 
systeme. 

11. Systeme embarque selon la revendication 8, caracterise en ce 
15 que les classes sont indexees suivant Tordre classes publiques puis classes 

en paquetages prives, et les attributs ou methodes suivant I'ordre attribut ou 
methode public, protege, en paquetage prive et en classe privee. 

12. Systeme embarque selon la revendication 11, caracterise en ce 
que la memoire non volatile programmable comprend plusieurs modules API 

20 comprenant des classes systeme, deux tableaux de representation (101, 
103) des modules, Tun pour les modules API et Tautre pour les modules non- 
API, et le module principal, et deux tables (102, 104) d'association MID/IMi 
correspondant chacune a un tableau de representation des modules. 

13. Systeme embarque selon la revendication 10, caracterise en ce 
25 qu'il comprend une classe gestionnaire d'acces "Access manager" d'un 

module API (105) comprenant une methode permettant de creer une 
instance d'un module de service, par Tintermediaire du module principal, 
ladite classe presentant une protection iui interdisant d'avoir plus d'une 
instance. 

30 14. Precede d'execution d'une application d'un systeme embarque 

multi-application, comprenant un environnement d'execution incluant une 
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machine virtuelle compreriant un interpreteur de langage de type 
pseudocode intermediaire, et des interfaces de programmation d'application 
(API), caracterise en ce que, lors de I'execution du pseudocode intenmediaire 
d'un module de service, correspondant a une application, referencee dans 
un tableau de module, la reference a une methode ou un attribut dans le 
pseudocode, codee sur au moins trois multiplets (bytes) correspondant a 
une reference a une classe interne (II) ou externe (IE) au module, un numero 
de classe (NCI) et un numero de methode (NM) ou d'attribut (NA), une 
reference externe au module est interpretee par la machine virtuelle comme 
une reference a rindex d'un module API du tableau du ou des modules API . 

15. Precede d'execution d'une application d'un systeme embarque 
multi-application selon la revendication 14, caracterise en ce que, sur 
reception d'une demande d'execution d'un module de service presentant un 
Identificateur (MID), Tenvironnement d'execution accede a la classe d'entree 
d'un module principal comprenant le programme principal du systeme, le 
module principal installe une instance d'une classe speciale "Access 
Manager" d'un module API, gerant Tacces a un module de service, et utilise 
une methode de cette classe permettant de creer une instance de la classe 
d'entree du module de service demandee, par I'intermediaire d'une table 
d'association de Tidentificateur a Tindex du module dans un tableau dans 
lequel le module est reference, I'instance etant retournee par la methode au 
programme principal. 
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Les documents de families de brevets sont indiqu^s en annexe 



Categories speciales de documents cit^: 

*A* document ddftnissant Tdtal general de ta technique, non 

consid^ comme parUculi^rement pertinent 
'E* document ant^rieur. mais public d ta dale de d^p6t international 

ou aprte cette date 
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*T* document ultdrieur public apres la dale de d6p0t international ou ta 
date de priorite et n'appartenenant pas d Petat de ta 
technique pertinent, mais cite pour comprendre le principe 
ou la theorte constituant la base de Tinvention 

'X* document particulierement pertinent; rinven tion revendiqu6e ne peut 
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